Protocols for IP-based mobility management as being considered for future mobile communication networks are designed in such a way that assignment of IP addresses or IP address prefixes can be delegated from entities being associated with mobility management to another dedicated entity of the network, such as for example a server for Dynamic Host Configuration (e.g. DHCP servers) or Authentication and Authorization (e.g. AAA servers).
Prior art works that are relevant in connection with address delegation include the following documents:                Proxy Mobile IPv6 (draft-ietf-netImm-proxymip6-11.txt)        DHCPv6 Based Home Network Prefix delegation for PMIPv6 (draft-sarikaya-netImm-prefix-delegation-01.txt)        Requirements for IPv6 Prefix Delegation (IETF RFC 3769)        Radius Delegated-IPv6-Prefix Attribute (IETF RFC 4818).        
For the sake of simplicity, addresses or address prefixes will be shortly referred to as ‘address’ hereinafter. Entities being associated with mobility management in a mobile communication system will be shortly referred to as ‘mobility entity’ hereinafter. Entities getting delegated address assignment functions from mobility entities will be referred to as ‘configuration component’. Further, the term “communication” is to be understood in a broad sense and includes all kinds of data exchange between mobile network nodes, in particular voice, video and multimedia data.
Generally, to retrieve a valid address for an attaching mobile node, the mobility entity which ensures reachability of mobile nodes requests the configuration component for a valid IP address. In return, the configuration component provides the mobile node an IP address and stores the mobile node's identifier together with the assigned IP address in its local database. Therefore, according to the configuration components' database entries, a mobile node can always be linked to the assigned address (or prefix).
FIG. 1 depicts a mobile communication system 1, where two mobile devices—mobile node A and mobile node B—get registered with different mobility entities being denoted mobility entity A and B. Both mobility entities A and B delegate address (or address prefix) assignment to a configuration server, respectively. In the depicted scenario both mobility entities A and B have chosen the same configuration server.
More specifically, in a first step (denoted step A1 and B1, respectively) each mobile node sends a registration request to the respective mobility entity. Alternatively, a network entity (e.g. mobility gateway according to Proxy Mobile IPv6) takes over the role of the mobile node to send such registration request to the mobility entity. In steps A2 and B2, respectively, the mobility entities A and B delegate address assignment to the configuration server. The configuration server assigns addresses ‘Addr A’ (for mobility entity A) and ‘Addr B’ (for mobility entity B) and provides them back to the requesting entity, as illustrated in steps A3 and B3, respectively. To complete the registration procedure, mobility entity A (and B, respectively) sends a registration reply to mobile node A (to mobile node B, respectively) including the assigned address ‘Addr A’ (‘Addr B’, respectively), which is depicted in FIG. 1 in step A4 (step B4, respectively). Alternatively, the registration reply is sent to the network entity, which sent the request on behalf of the mobile node. In such case, this network entity forwards the assigned address to the mobile node.
In the specific scenario described in connection with FIG. 1 problems might arise, for instance, when mobile node A intends to send a packet to mobile node B. In this case all data traffic would take a default predefined path through both mobility entities. Such default routing path might be unfavorable and could possibly lead to network resources being unduly wasted. Even worse, the default path might soon get overloaded.